Day 23｜模型架構與金鑰儲存設計

昨天聊了 Provider Adapter 怎麼處理多家廠商的差異。今天要往下一層，聊建立一個模型背後的資料架構，還有 API Key 這種敏感資料要怎麼保護。

建立一個模型，要先建 Credential 再建 Deployment

在這個系統裡，要讓一個模型能被呼叫，分兩步：先建立一筆 Credential，填入名稱、要用哪種 adapter、Base URL，還有 API Key：

Credential 建好之後，才在它底下新增 Deployment——選擇要掛在哪個 Credential 底下，填入對外的 Public Model Name、真正要打給廠商的 Provider Model ID，以及決定 Fallback 順序的 Priority：

同一個 Public Model Name 可以掛好幾筆 Deployment，畫面上依 Priority 排序顯示，一眼就能看出 Fallback 的順序。

Fallback的功能會在後續文章詳細說明，這邊先呈現模型建立的流程。

為什麼要拆成兩張表

Credential 跟 Deployment 拆成兩張表，其實從一開始構思時就是這樣想的：先設好 Credential，通過廠商的身份驗證，再在底下設定要用的模型——這樣的架構本身就足以支援多模型，也順便為 Fallback 打好了地基。只是前期跟 AI 溝通時沒有講清楚，導致最初的實作走偏成單一張表，後來才又做了一次架構上的修正，這也算是這個專案實際遇到的一個問題：想法對了，但沒說清楚，AI 一樣會做出跟原本設想不一樣的東西。

至於 Public Model Name 對應 Provider Model ID 這個分離，一開始就設定好了。原因很直接：打給廠商的必須是正確的、正式的模型名稱，但在服務上，使用者想看到的名字不見得需要完全對應——甚至可以讓使用者自己取暱稱。這個分離除了能很好地支援 Fallback 機制，如果之後同一個服務底下想同時支援好幾個模型，這個設計一樣派得上用場。

API Key 保護的底線

「不能把 API Key 明文存進資料庫」這條規則，從一開始規劃時就定死了，沒有猶豫過要不要做。理由很直接：這把 key 打的是真實廠商的帳號，一旦外流，造成的是實際的金錢損失——這種風險等級，不是「個人版可以簡化」的範圍，必須從一開始就用加密處理。

小結

這個模組的架構看似只是兩張表跟一段加密邏輯，但背後是兩個不同層次的判斷：Credential／Deployment 的分離，是為了讓架構本身就能撐住多模型跟 Fallback；API Key 加密，則是一條從一開始就沒得商量的安全底線。

明天要聊 Gateway 跟 Fallback——統一入口的用途，以及雙重容錯設計是怎麼想出來的。